home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Aminet 2
/
Aminet AMIGA CDROM (1994)(Walnut Creek)[Feb 1994][W.O. 44790-1].iso
/
Aminet
/
comm
/
term
/
JRC102R.LZH
/
Q&A.doc
< prev
next >
Wrap
Text File
|
1991-04-03
|
18KB
|
385 lines
JR-Comm 1.02 - FREQUENTLY ASKED QUESTIONS
-----------------------------------------
This text was extracted from chapter 19 of the JR-Comm 1.02 users manual.
- MY FILE TRANSFERS ARE MUCH SLOWER THAN THOSE WITH OTHER PROGRAMS. WHY?
There are several causes of this happening. If one or more are
present, you will get very slow transfer rates as their effects are
cumulative. Most of this discussion pertains to ZMODEM downloads,
which is by and large, the most common type of transfer performed with
JR-Comm.
There are three options that standout above all others in terms
of slow file transfer performance. One, the "Escape ctrl chars"
option in the FILE TRANSFER PARAMETERS requester effects ZMODEM file
transfers only, but tremendously. DO NOT USE THIS OPTION UNLESS YOU
ABSOLUETLY NEED TO!!!
The second option, "File saver" in the GENERAL PARAMETERS
requester effects any type of download. What this causes JR-Comm to
do is to close and then reopen the file each time a disk write
operation is performed. By doing this, the file is gauranteed to
contain some data if a system crash occurs during a file download.
What this also means is that the file transfer is going to be slowed
down significantly since there is additional overhead needed to reopen
and reposition the file pointer each time an access occurs. You have
to determine if the throughput penalty this option imposes is less of
a factor then possibly losing a file.
The last reason for slower transfers has to do with high-speed
ZMODEM and YMODEM-g uploads only. If the "Overdrive" feature is not
enabled, JR-Comm will not do a burst mode send of data out the serial
port. Although it can speed up throughput by a good margin, it has
the drawback of increasing error recovery time. It is not recommended
for noisy connections or for baud rates below 9600bps.
Although not a severe, having XON/XOFF handshake active when
starting a ZMODEM file transfer will also slow it down somewhat. The
confusion with XON/XOFF arises from the fact that JR-Comm does not
deactivate it when a ZMODEM transfer is initiated like most of the
other Amiga communications programs that are out there. This is not
correct though because, unlike XMODEM technology protocols, ZMODEM is
a full streaming protocol designed for packet switched networks that
may overflow portions of a busy network without XON/XOFF handshake
active to regulate data flow.
The "Disk check" option will slow down the beginning of a file
transfer due to JR-Comm performing a free space check before
proceeding with the transfer.
The "Logfile active" option will also slow down batch transfers
since a write to the logfile performed at the completion of each file
transfered.
- I'M GETTING DOWNLOAD ERRORS AT OR ABOVE 9600BPS WITH AN MNP MODEM.
Since an MNP modem is an error correcting device that gives you an
error free connection, any errors at high baud rates can only mean one
thing; data being lost between the modem and computer. The cause of
this is due to the cpu getting locked-out long enough for the most
recently received data byte to be overwritten by the next incoming
byte. Unfortunately, the internal serial port does not buffer these
bytes like some of the more advanced UARTS (Universal Asynchronous
Receive Transmit device) available these days. Thus, the cpu has a
fairly critical "window of opportunity" in order to successfully fetch
data as it is received.
Unlike the IBM style computer, the Amiga does not have the
ability to simply pop in an alternate (and more powerful) UART that
would eliminate this problem. Do not despair however. There are a
few simple things that you can check to determine the cause of these
bytes getting lost.
Using an 8 or 16 color screen can have a direct effect on these
problems, try dropping down to a Workbench or 2 color screen to see if
this eliminates the errors.
Next, are you running JR-Comm or any other task with an
excessively high priority? Do you have any device drivers (hard disk
drivers are a common one) that run at an unreasonably high priority?
Is the hard disk controller you're using a programmed I/O version? If
it is, contact the manufacturer for help. Use the diagnostic key
sequence in JR-Comm to create a ram:jrc.diag file and examine its
contents or contact the support BBS for additional help.
If the task priority in the GENERAL PARAMETERS requester hasn't
been modified, you may want to bump it up one or two at a time and see
if this cures the problem.
Having more than two floppy drives connected (one internal and
one external) will definitely give you problems with the internal
serial port. This is due to AmigaDOS checking for a changed disk once
every second or so for each drive. The same holds true for certain
hard disk controller devices that have more than two or three
partitions active. Believe it or not, AmigaDOS also checks each
partition once every second to see if it too has been changed!
Finally, check if you are running any cpu intensive tasks in the
background while you're downloading.
Although the Amiga is a multitasking machine, the resources
available are finite, especially when you're running JR-Comm (or any
communications program) at 9600bps or 19.2kbps (anything higher than
19.2kbps is definitely not recommended with the internal port).
Remember that the internal port can't buffer the data it receives, so
don't bog down the cpu or it won't be able to respond to the data fast
enough to prevent it from being overwritten.
If you still continue to receive errors contact the support BBS
for any additional help that may have been discovered since the
printing of this manual.
As an aside, you may wish to look into a third party serial board
for the A2000 and A3000 series of Amiga computers. These boards can
greatly reduce the problems you may be having, especially if you can't
completely eliminate them.
- WHY DOESN'T JR-COMM HAVE A YMODEM-batch PROTOCOL?
It does. YMODEM is a batch protocol, thus calling it "batch" would be
redundant. There are really only two variations of TRUE YMODEM(tm).
The first is YMODEM and the second is the YMODEM-g protocol for use
with reliable data connections, such as an MNP modem.
The trouble lies in the fact that some telecommunications
software authors took it upon themselves to implement only some of the
features of YMODEM and still call it YMODEM. The most common variant
being what is now properly called XMODEM-1k. Later, after realizing
the errors of their ways, they added YMODEM-batch, but called it that
to save face with their users.
If the protocol that calls itself YMODEM does not send filename,
size and date information (JR-Comm will tell you this by "stepping
down" to XMODEM), it is really XMODEM-1k.
There are some other versions that will send this information,
but will not support batch operation. You can still use JR-Comm's
YMODEM in these instances too.
Finally, there are some very old versions of YMODEM that you may
run into that cannot handle the 1024 byte block that is in widespread
use today. This is the reason for the YMODEM and YMODEM-1k options in
the FILE TRANSFER PARAMETERS requester. In almost all cases, leave
the 1k version selected. Only use the other for instances where the
receiver must have 128 byte blocks sent.
JR-Comm has enough intelligence built-in to handle almost any of
the mutant versions of this protocol that you may run into. If you do
run into an especially uncommon strain of this protocol, please report
it to the BBS so that it can be modified to deal with it in a future
release.
- WHY DOES JR-COMM SOMETIMES TAKE SO LONG TO ABORT A FILE TRANSFER?
JR-Comm tries very hard to prevent leftover data from an aborted file
transfer from splattering all over your display. If the wait is
extraordinarily long you can click on the close window gadget a few
times to cause a hard abort to occur regardless of what data is left
in the pipe.
Although ZMODEM transfers will generally abort faster, the XMODEM
technology protocols can take a good deal of time to abort. The main
reason for this is that the receiver can only detect an abort sequence
at the start of a block. It cannot determine this while receiving the
data portion of the block. So, you may have to wait for as many as
1,028 bytes to be sent or received before it will begin the abort
sequence. The "Overdrive" option will aggravate this delay
substantially for low baud rates.
- ALL FILE TRANSFERS IMMEDIATELY ABORT WITH "Carrier not detected..."
This is related to the previous problem except that the carrier detect
signal (DCD) is never active, even when it should be. The two most
likely causes for this occurring would be a defective serial cable or
modem. Check the modem manual to verify that your modem does have a
functioning DCD signal and that the serial cable passes this signal.
- ATREDES BBS ZMODEM DOWNLOADS SOMETIMES HAVE "WEIRD" FILE SIZES.
Some versions of the Atredes BBS system had a bug that gave incorrect
information for this protocol. The file will be received correctly
though. Inform the sysop of that system to upgrade to a newer
version.
- FILE TRANSFERS WITH A BBS-PC! SYSTEM <INSERT YOUR PROBLEM HERE>.
Unfortunately, there is no easy way to determine which version of
BBS-PC! you are really dealing with. Although it may "say" that it is
version 4.20 (or whatever), it could be any one of a number of
releases due to the publisher of this product not bumping the version
number as they fix things. The only certain way is to know the file
size of the executable for this program and, as a caller to the
system, you cannot find this out.
Contact the sysop of the system in question to determine what is
the best way to correct the problems you're experiencing with this
BBS.
- WHY DO DOWNLOADS SOMETIMES TAKE LONGER THAN UPLOADS TO THE SAME SYSTEM?
This is not a problem. It is simply that any download, regardless of
the protocol being used, is entirely dependent on the speed of the
sending system. You can only receive a file as fast as it is being
sent to you.
- JR-COMM WILL NOT ENABLE CTS HANDSHAKE.
In order to use CTS/RTS handshake, your modem must have the DSR and
CTS signals active. Check your manual so that you can set the modem
to always have DSR active and have CTS remain active (but not set high
permanently) when offline.
- THE ONLINE TIMER IS ALWAYS COUNTING, EVEN WHEN OFFLINE.
-and-
- THE DIALER REFUSES TO DIAL, REPORTS: "Exiting, carrier present."
These two problems are due to the carrier detect signal (DCD) always
being active. Check the manual to the modem for the proper command
and/or hardware switch in order to set the modem so that this signal
is only active when a carrier signal is present.
If the modem (or cable) doesn't allow you to correct this
problem, you will have to disable the carrier detect logic in JR-Comm
by setting the button gadget "Ignore carrier detect" which is located
in the MODEM PARAMETERS requester.
- THE DIALER ALWAYS REMOVES AN ENTRY AFTER THREE DIAL ATTEMPTS.
You modem must be able to RELIABLY detect a busy signal or it will
return a NO CARRIER response. If three of these responses are
received for a selected entry the dialer will deselect it.
If your modem does not detect busy signals, also known as "blind
dialing", or it is not reliably detecting them, you must activate the
"Ignore No Carrier" option in the MODEM PARAMETERS requester to
deactivate this feature of the dialer.
- THE DIALER ALWAYS SETS THE BAUD RATE TO SOMETHING OTHER THAN THE
SELECTED OR CONNECTED RATE, WHY?
There are two reasons why this would happen. The most common one
would be have the "Auto-baud" option in the MODEM PARAMETERS requester
active while your modem is not set (or capable) of returning extended
result codes for the "CONNECT" message. The second reason is if your
modem does not adhere to the Hayes standard for these extended result
codes. Please refer to section 2.8.5 for more details about the auto-
baud feature.
- THE MODEM SOMETIMES "MISSES" THE DIAL COMMAND SENT BY THE DIALER.
Some modems have trouble decoding an "AT" command sequence when the
characters are sent too fast. Set the "Dial pacing" parameter in the
MODEM PARAMETERS requester to a value that allows your modem to
reliably receive the dial command. This value represents tenths of a
second delay between each character in the command string.
- MY MACROS ARE SENDING INCORRECT DATA WHEN USING THE IBM DOORWAY MODE.
This is normal. Function key macros are disabled during Doorway mode
due to JR-Comm emulating the hexadecimal scan key codes that are sent
whenever a key is pressed while this mode is active. For this reason
you cannot have macros when using this mode.
- JR-COMM SOMETIMES REPORTS THAT IT COULDN'T OPEN A WINDOW.
You're running JR-Comm on a system that has little free memory. Use a
screen with less colors.
- I'M USING JR-COMM TO DIAL OUT ON A BBS LINE. HOW DO I PREVENT IT FROM
EXITING AFTER RECEIVING A "RING" OR 3 "NO DIALTONE" MESSAGES?
The "RING" message in the MODEM PARAMETERS REQUESTER will have to be
deleted in order to disable that feature. The "NO DIALTONE" feature
of the dialer can't really be disabled, but a work around has been
developed that will "fool" the dialer.
What you need to do is first delete the "NO DIALTONE" string.
Now, change the "NO CARRIER" to "NO DIALTONE". Lastly, set the
"Ignore no carrier" option in the MODEM PARAMETERS requester.
What this accomplishes is that the dialer will treat the "NO
DIALTONE" response as if the modem was a dumb Hayes that was using
blind dialing. Although an intelligent modem that has a call
progression feature can still return a "NO CARRIER" response if the
modem times out without the remote system picking up or if it fails to
detect a "BUSY" signal, the "Ignore no carrier" feature will prevent
the dialer from removing the phone entry from the selected list.
- WHY DO 4 DOTS APPEAR IN THE STATUS LINE WHEN USING VT-10x?
These dots represent the four LED indicators on a real VT-10x
terminal. They are software controlled by the remote system during
operation. An '*' character is used to indicate that the LED is "on".
- JR-COMM HAS TROUBLE KEEPING UP WITH 16 COLOR ANSI. WHY?
If you're using an Amiga that only has chip ram or "pseudo-fast" ram
instead of "true" fast ram, the cpu is going to be locked-out during
display and scroll functions. An 8 color screen should help eliminate
the slow operation that occurs on systems with no true fast ram.
True fast ram is different than ram expansion that resides at the
hexadecimal $C00000 address, such as the 512k A501 expansion for the
A500.
A 16 color screen also is limited to 2400bps operation. Somewhat
less for PAL screens, even if fast ram is installed. If you're using
a high-speed modem, you should drop down to at least an 8 color
screen, or risk serial data loss. See the next problem discussion
which is closely related to this one.
- WHY ARE THE COLORS ORDERED DIFFERENTLY THEN A TRUE MS-DOS MACHINE?
JR-Comm uses a translation table to convert the ANSI sequences that
change color to the correct hue. This was done to make the various
requesters and default white on black text look "right" on the Amiga.
If the "correct" color ordering was used, the default text would have
been red for both the terminal and the string gadgets in the
requesters.
The color scheme was further designed to allow the gadgets and
their labels to be readable from a 2 color to 16 color screen.
- BUT, DID IT HAVE TO EMULATE THE "FLICKER" OF THE OLD CGA MONITORS TOO?
The slight flicker you see as colored text scrolls up the screen is a
result of the blitter scrolling each of the four component bitplanes
that make up a 16 color screen one at a time. Since the total scroll
operation takes longer than the time to refresh and paint the bitplane
data once or twice, you see a small flicker. Some of the colors are
more prone to this than others. The color scheme of the palette was
also modified to take this into account by separating some of the more
offending colors to minimize this effect. Unfortunately, this wasn't
completely successful.
A future version of JR-Comm may have a better solution to this.
Only authorized system calls and methods were used to prevent problems
from occurring with the new version(s) of Kickstart and Workbench that
were still under development when JR-Comm 1.02 was released.